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A system for remotely managing a network of waste con- 
tainers (12), each of which is associated with a monitoring 
unit (38), utilizes a central computer (50) having a commu- 
nication link to each monitoring imit (38). The central 
computer (50) provides a dynamically updated display, via 
a display module (60) having a full container window (or 
zone) which shows full containers (12), an alarm window (or 
zone) which shows non-full containers (12) having an alarm 
condition, and a container status window (or zone) which 
shows non-full containers not having an alarm condition. 
The system additionally includes one or more remote moni- 
tors (404) capable of providing user access to the container 
status information maintained by the central computer (50, 
402). 
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SYSTEMS FOR REMOTE MANAGEMENT OF A 
NETWORK OF WASTE CONTAINERS 

CROSS-REFERENCE TO RELATED 
APPLICAriON(S) 
[0001] This is a continuation-in-part application of U.S. 
patent application Ser. No. 09/590,214, filed Jun. 8, 2000, 
entitled "SYSTEM FOR REMOTE MANAGEMENT OF A 
NETW'-ORK WASTE CONTAINER", which claims priority 
from provisional U.S. patent application Ser. No. 60/188, 
612, entitled "USER INTERFACE," tiled Mar. 7, 2000, the 
subject matter and entire writings of which are incorporated 
herein by reference. 

STATEMENT REGARDING FEDERALLY 
SPONSORED RESEARCH OR DEVELOPMENT 
[0002] Not appUcable. 

REFERENCE TO A MICROFICHE APPENDIX 
[0003] Not appUcable. 

TECHNICAL FIELD 

[0004] The invention relates generally to waste collection 
and removal systems. More particularly, the invention 
relates to systems for monitoring and managing the status of 
a number of waste containers, such as trash compactors, 
which are equipped with compacting assemblies, or open- 
top containers which arc not equipped with compacting 
assemblies, in a manner that permits a user to quickly 
determine at a central location the current status of all 
containers in the container network. The invention also 
relates lo syslcius lor managing communications between a 
central computer and a plurality of monitoring units, each 
located at a respective container site. The invention also 
relates to systems for permitting user-modified polling of 
such monitoring units. 

BACKGROUND OF THE INVENTION AND 
TECHNICAL PROBLEMS POSED BY THE 
PRIOR ART 

[0005] Much effort has been invested to provide efficient 
and economical systems for facilitating waste collection 
from a network of waste containers. Typically, one or more 
waste collection service providers, or haulers, will service a 
waste container network that includes a large number of 
waste containers situated at different geographical locations 
in a given region. Usually, these containers are provided 
with a compacting device equipped with a hydraulic ram for 
compacting the trash or, they may consist of open-top 
containers which are not equipped with a compacting 
device. When a container becomes full, a hauler, typically a 
large truck, is dispatched to the site to empty the container. 
Since each hauler trip typically involves significant cost, and 
since the amount of waste generated at a particular location 
typically varies in an unpredictable manner, the status of 
each container in the network is usually monitored in some 
way to ensure that haulers are dispatched to full containers 
in a timely and economical manner. 

[0006] It is known to provide waste container monitoring 
systems that employ a respective processing or monitoring 
unit and a respective communications link associated with 
each waste container. Such systems are disclosed in U.S. 



Pat. No. 5,303,642, the entire writing and subject matter of 
which are incorporated herein by reference. These systems 
detect container fullness by monitoring the maximum pres- 
sure applied to the hydraulic ram during a compaction 
stroke. The monitoring unit includes a microprocessor for 
making a container status, i.e., fullness or emptiness, deter- 
mination. When a full or empty container determination is 
made, the monitoring unit initiates an outbound call and a 
signal representing the container status is communicated via 
communications liiik to a remote central location. For 
example, the monitoring unit initiates an outbound call when 
it determines that the associated container is full and sends 
a facsimile message to a remote location to indicate to a 
human administrator that a particular container is full or 

[0007] Other prior art systems, such as those disclosed in 
U.S. Pat. No. 5,016,197, provide an automated trash man- 
agement system to monitor the fullness of a plurality of trash 
compactor/container units based upon an analysis of the 
number of cycles of the compactor and the hydraulic pres- 
sure associated therewith. Such systems uuhzc a iiioniloring 
unit that includes a pressure sensing unit associated with 
each waste container. The monitoring unit Iransiuils data, 
representing instantaneous hydraulic pressures, lo a central 
computer via communications link, such as a telephone 
system. Ihe central computer dclcrmjucs the iullness of 
each trash compactor based on the transmitted pressure data. 
The computer may compile a database for each trash com- 
pactor and compactor fullness may be determined from the 
database. 

[0008] As waste container networks grow in size, the 
management of Ihc sliilus inrormali()n pnwidcd lor each 
container in the container network becomes increasingly 
difEcult. A human administrator of the container network is 
presented with and/or required to manage a great deal of 
information. Thus, a determination of which containers 
require immediate attention, i.e., which containers require 
emptying or are experiencing an error condition, often 
becomes overly burdensome. Accordingly, those of ordinary 
skill in the art will recognize a need for a system for 
facilitating the efficient management of a waste container 
network by providing comprehensive information in a man- 
ner that permits a human user to quickly and accurately 
determine the status of all containers in a container network. 
Moreover, there is a need for a system that is versatile in that 
it is compatible with monitoring units which make a fullness 
determination at the container site and with monitoring units 
which provide information used to make a fullness deter- 
mination at a central computer. 

[0009] Another problem with prior art waste container 
management systems is that they do not provide for real- 
time dynamic updating of container status. Nor do they 
provide for user-controlled polling of the containers in the 
network. For example, in systems such as the one disclosed 
in U.S. Pat. No. 5,016,197, where pressure readings are 
conveyed to a central computer, the central computer typi- 
cally conducts polling of a particular container according to 
a preset and rigid schedule. Thus, in cases where a user 
desires immediate information about a container's status, the 
information is not readily available until the container is 
polled by the system. Another related consequence of the 
prior art polling techniques is that the information presented 
to the user may not be accurate or up to date. Thus, it would 
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be desirable to provide a waste management sj'stem which 
provides for real-time dynamic updating of container status 
and which permits a user to modify or control the poUing 
schedule associated with particular containers. 
[0010] Yet another problem with prior arl waste conlainer 
management systems is that they do not provide for efficient 
updating of container status information. In a typical prior 

report container slaliis infornialion. In addilion, die central 

However, if outbound calls are being made, the receipt of an 
inbound call from a full container in prior art systems may 
be prevented or delayed, especially in systems that provide 
only a single communications channel, resulting in outdated 
information being presented to the user. Thus, the prior art 
does not provide an efiScient method for managing inbound 
and outbound calls in a manner that provides for efScient 
updating of container status information. Accordingly, there 
is a need for such a system. 

SUMMARY OF THE INVENTION 

[0011] The benefits and advantages described above are 
realized by the present invention which provides a system 
for remotely managmg a network of waste containers m a 
container network which provides comprehensive container 
network information to a user in a manner that enables the 
user to quickly and accurately determine the status ol all 
containers in the contamer network. In a prclcrred embodi- 
ment, the invention provides a central computer having a 
communication link to each of the monitoring units lor the 
respective containers in the container network. C ommuni- 
cations with the monitorinu units in the contamer network 
are managed by a communications module on the central 
computer. The central computer is adapted to provide a 
dynamically updated display which distinguishes lull con- 
tainers from other containers in the network. In a preferred 
embodiment, the invention provides a graphic display with 
a fuU container window or zone in which identifiers for the 
full containers displayed, along with other information, such 
as container location, pressure and compaction readings, 
account information and contact information for the waste 
collection service or hauler associated with the container. 
The display is provided by a display module in conjunction 
with a full container module which cooperates with a 
container database to determine which containers in the 
container network have reported full status and periodically 
redraws the full container zone or window to provide an 
updated Ust of full containers. 

[0012] The container database preferably includes a con- 
tainer table and a transaction table. The container table is a 

relatively static database containing a container record for 
each container in the network. Each container record 
includes a container identifier and various information asso- 
ciated with the container, including operating parameters, 
accounting information and geographical location. In a 
preferred embodiment, the container record includes a full 
status flag which is used to indicate whether a fullness 
determination has been made by the monitoring unit asso- 
ciated with the container and communicated to the central 
computer. Alternatively, the container record may include a 
pressure threshold and a fullness determination may be 



made at the central computer. The transactions tabic is a 
relatively dynamic database and contains transaction records 
resulting from each communication session attempted or 
established with a monitoring unit in the container network. 
Each transaction record contains information identifying the 
associated container, as well as information identifying the 
type of transaction resulting from the communication 
attempt with the monitoring unit associated with the con- 

[0013] The invention also provides an alarm zone or 
window for distinguishing to the user which containers in 
the container network have an alarm condition. The trans- 
action table is adapted to contain transaction types that 
include errors that occur during communication attempts. 
An alarm module cooperates with the transaction table to 
determine which containers have an alarm condition and, in 
conjunction with the display module, provides a graphic 
display listing identifiers for the containers with an alarm 
condition. Like the fuU container module, the alarm module 
periodically reviews the container database and updates the 
alarm zone or window to reflect the current status of the 
containers in the container network. 

[0014] The invention also provides a container status zone 
or window tor displaving the non-lull containers which do 
not have an alarm condition. A container status module 
cooperates with the transaction table to determine which 
containers are neither full nor have an alarm condition and, 
in conjunction with the display module, provides a graphic 
display listini; idcniiliers for the containers that are neither 
lull nor have an alarm condition. 

[0015] The lull container zone, alarm /.one and container 
status zone ol the invention provide a simple and eflicient 
way lor an operator to quicklv dcterinnic the status ol all 
containers in the container network. Moreover, the full 
container zone distinttinshes lull containers Iriuii the rest of 
the contamers in the container network such that the user 
may quickly determine which containers are in need of 
emptying. Similarly, the alarm zone distmguishes contamers 
having an alarm condition from the rest of the contamers in 
the network and permits quick determination by a user of 
containers experiencing an error condition. 

[0016] According to yet another feature of the invention, 
automatic polling may be scheduled by the user. PoUing 
involves an outbound call or communication initiated by the 
central computer to the monitoring unit for a selected 
container in the container network. A poUing module pro- 
vides a user interface to enable a user to enter polling 
parameters and the polling module updates the container 
database accordingly. The container records stored in the 
container table preferably contain fields for an automatic 
polling flag and a polling interval. The polling module 
accepts user input and stores the appropriate automatic 
polling data in the container record. The communications 
module is adapted to periodically review the container table 
and schedule poUing sessions according to the parameters in 
the automatic poUing flag and polling interval fields in the 
conlainer records. Preferably, the polling sessions are 
queued into a session stack on a first-in-first-out basis. In this 
manner, the user can control the polling interval for each 
container in the container network. Moreover, the ses.sion 
stack permits scheduled polling sessions, as well as on- 
demand polling sessions requested by the user, to be queued 
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such that the user need not be present for the polhng sessions 
to be performed. The communications module conducts 
polling of the containers in the network in a manner that is 
preferably transparent during the user's observation of the 
full container zone, container status zone and alarm zone. 
The communications module is preferably implemented as a 
communications thread that is separate from and executed in 
the background relative to the main thread of execution 
represented by the operation of the fiill container module, 
container status module and alarm module. 

[0017] According to yet another feature of the invention, 
the communications module is adapted to manage the sched- 
uling and execution of polling sessions while permitting the 
receipt of inbound full or empty calls initiated by monitoring 
units in the container network. The communications module 
provides a waiting period or delay between the execution of 
scheduled polling events to permit receipt of inbound calls. 
Preferably, the receipt of an inbound call preempts the 
polling events already queued in the session stack such that 
the calling session associated with the inbound call is 
performed immediately. This ensures that inbound calls 
from monitoring units, for example, inbound calls indicative 
of a full container in the network, result in immediate 
updating of the container database and immediate appropri- 
ate updating of the full container zone, container status zone 

[0018] According to yet another feature of the invention, 
the container status information could is accessible via one 
or more remote monitors, which are communicatively 
coupled to central computer, thereby enabling remote user 
access. In at least one aspect of the feature, the communi- 
cation occurs via a global public wide area communication 
network. 

[0019] Niimerniis other advantages and features of the 
present invention will become readily apparent from the 
lollowirjg detailed description of the invention, from the 
claims, and from the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0020] In the accompanying drawings that form part of the 
specitication, and in which like numerals are employed to 
designate like parts throughout the same, 

[0021] FIG. 1 is a block diagram showing the basic 
elements of a waste compacting unit according to a preferred 

embodiment of the invention; 

[0022] FIG. 2 is a block diagram of a waste container 
network according to a preferred embodiment of the inven- 

[0023] FIG. 3 is a block diagram of the basic components 
of a computer suitable for implementing an exemplary 
system according to a preferred embodiment of the inven- 

[0024] FIG. 4 is a block diagram depicting the relation- 
ships between the various modules and databases associated 
with an exemplary embodiment of the present invention; 

[0025] FIG. 5 depicts an exemplary display of a full 
container zone, a container status zone, and an alarm zone 
according to a prefened embodiment of the present inven- 



[0026] FIG. 6 is an exemplary flow diagram of the steps 
performed by an exemplary full container module, container 
status module and alarm module according to the invention 
to render and update a display such as the one shown in FIG. 
5; 

[0027] FIG. 7 depicts an exemplary display of a menu 
option enabling a user to access a container parameter 
editing function according to a preferred embodiment of the 

[0028] FIG. 8 depicts an exemplary display of a container 
parameter dialogue window or pane according to a preferred 
embodiment of the present invention; 

[0029] FIG. 9 depicts a flow chart showing the steps 
performed by an exemplary communications module and 
polling module to create poll sessions according to the 

[0030] FIG. 10 depicts a flow chart showing the steps 
performed by an exemplary communications module to 
permit receipt of inbound calls while conducting calling 
sessions scheduled in a calling session stack according to a 
preferred embodiment of the invention; 

[0031] FIG. 11 is a schematic iUtistration of a session 
stack used to determine container status according to the 
invention; 

[0032] FIG. 12 is a diagrammatic illustration representing 
a data exchange between a monitoring unit and a central 
computer during a polhng session in an exemplary system 
according to the invention; 

[0033] FIG. 13 depicts the remote access portion of one 
exemplary system for remotely managing a waste container 
network including a central computer/data server and one or 

[0034] FIG. 14 is a simplified block diagram of one 
embodiment of the central computer/data server, illustrated 
in FIG. 13; and 

[0035] FIG. 15 is a simplified block diagram of one 
embodiment of a remote monitor, illtistrated in FIG. 13. 

DETAIT ED DESCRIPTION OF THE 
PREITRRED EMBODIMEN f 

[0036] While this invention is susceptible of embodiment 
in many diflerent forms, this specification and the accom- 
panying drawings disclose only some specific forms as 
examples of the invention. The invention is not intended to 
be limited to the embodiments so described. The scope of the 
invention is pointed out in the appended claims. 

[0037] Referring to FIG. 1, a typical waste container, 
generally depicted by the reference numeral 10, includes a 
container 12, equipped with a compacting assembly having 
a hydraulic driver 16 which includes a ram 14, to compact 
waste received in container 12. ITie hydraulic driver 16 
receives pressurized hydraulic fluid via hydrauhc lines 17 to 
effect reciprocal movement of the ram 14 in a controlled 
manner using a shuttle valve 18. Hydraulic fluid is stored in 
a reservoir 20 which provides pressurized hydraulic fluid to 
the shuttle valve 18 and which is returned from the shuttle 
valve 18 via a return line 21. As will be recognized by those 
of ordinary skiU, the reservok 20, pump 22, shuttle valve 18 
and return line 21 form a hydraulic circuit 23. The afore- 
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mentioned container structure is well known in the art and 
the details thereof, which are set forth in U.S. Pat. No. 
5,303,642, are not necessary for an understanding of and do 
not form a part of the present invention. 
[0038] A monitoring anil, generally referenced by the 
numeral 38, provides an indication of the status of container 
10. For example, the monitoring unit 38 may comprise a 
pressure transducer 26 disposed in the hydraulic circuit 23 at 
the outlet of the pump 22 to generate a signal (P) represent- 
ing the hydraulic pressure beinij, applied to the hvdraulic 
driver 16. The siL;ual (P) is euriveyed tu a status processor 
42, which preferably includes a microprocessor based com- 
puter executing appropriate mstructions for determmmg 
container status based on the signal (P) and generating a 
container status signal (S), representing status information 
associated with the container 10. For example, the monitor- 
ing unit 38 may determine container status locally according 
to the method disclosed in U.S. Pat. No. .S..1().^,642 by 
determining the maximum pressure experienced by the 
transducer 26 during a compaction stroke of the ram 14, 
wherein the container status signal (S) represents a status 
flag indicating the full status of the container. Allernatively, 
the monitoring unit 38 may operate according to the system 
described in U.S. Pat. No. 5,016,197 and provide status 
information representative of hj'draulic pressures histori- 
cally applied to the hydraulic driver 14, wherein the status 
information is communicated to a central computer and the 
container status is determined remotely from the container. 
The monitoring unit 38 also includes a communication 
device 44, such as a modem, in communication with the 
status processor 42 through a communications interface 32. 
Communications device 44 conveys the status signal (S) via 
a communications link 36, which may comprise a wire- 
based communication system, such as a telephone network, 
or a wireless communication system. 

[0039] FIG. 2 illustrates an exemplary container network 
according to a preferred embodiment of the present inven- 
tion. A number of container 12A, 12R, 12C and 12D, each 
having respective monitoring units 38A, 38B, 38C and 38D 
commimicate with a central computer 50 via communication 
links 36A, 36B, 36C and 36D. It will be understood by those 
of ordinary skill in the art that the present invention is 
applicable to container networks having more than four 
containers and respective monitoring units. Typically, the 
number of containers in a container network may exceed one 
hundred. 

[0040] FIG. 3 illustrates the basic components of an 
exemplary central computer 50 suitable for implementing 
the system according to the invention. The central computer 
50 includes a microprocessor 52 and memory 54, intercon- 
nected for electrical communication through a system bus 
56. A storage device 58, which may typically include 
well-known storage devices, such as magnetic or optical 
disks, is also in communication with system bus 56. As is 
well-known in the art, memory 54 wiU contain digital data 
representing instructions for microprocessor 52. Storage 
device 58 may also include such instructions or data. Com- 
puter 50 also includes user-interface devices for enabling a 
user to interact with the computer 50. A display device 60, 
which typically comprises a cathode raj' tube or liquid 
crystal display, communicates with the system bus 56 and 
displays graphical information to the user according to 
instructions executed by the microprocessor 52. A user 



interface selection device 62 also communicates with the 
system bus 56 and may include a mouse or other pointing 
device. A keyboard 64 is also in communication with the 
system bus 56 to permit user-entry of alpha-numeric infor- 
mation. 

[0041] FIG. 4 illustrates the basic components or modules 
of an exemplary system according to the invention. Those of 
ordinary skill in Ihe art will understand that these modules 
or components are preferably implemented as a series of 
instructions for microprocessor 52 and stored in a computer- 
readable medium, such as memory 54 or storage device 58. 
[0042] An exemplary system 75 according to the inven- 
tion, inchides a container database 80 that contains various 
information relative to each of the containers in the con- 
tainer network. The container database is preferably a rela- 
tional database compatible with a commercial relational 
database management application such as "ACCESS" 
developed by Microsoft Corporation, of Redmond, Wash. It 
will be understood by those of ordinary .skill that the 
coiiiaincr table 81 and a transactions table 83 described 
herein are preferably in the form of separate but related 
databases contained in the gcncrically referenced container 
database 80. 

[0043] The container table 81 includes a number of con- 
tainer records corresponding to the number of containers in 
the container network. Each record contains various kinds of 
information associated with the respective container, as will 
be explained below. The container database also preferably 
inchides a transaction table 83, including a number of 
transaction records, each reflecting a transaction conducted 
relative to one of the containers in Ihe container network as 
will be explained in more detail below. A transaction record 
is created in the transactions table 83 by the communications 
module 82 each time a communications session is estab- 
lished with a monitoring unit 38 in the container network. 
Thus, the container database 80 is kept updated by the 
communications module 82, which interfaces with a com- 
munication device 84, such as a modem and which manages 
communications sessions with the monitoring units 38 in the 
container network. 

[0044] A full container module 90 retrieves information 
from the container database 80 and provides a signal to a 
display module 94, which contains appropriate instructions 
and drivers to provide a signal readable by the display device 
60. Full container module 90 in conjunction with display 
module 94 preferably function to generate a fuU container 
window or zone displaying a list of the full containers in the 
container network, as will be explained in more detail below. 
The full container module 90 is adapted to determine when 
new transaction records have been created and to send 
appropriate signals to the display module 94 to update the 
list of fuU containers displayed in the window or zone. 
[0045] An alarm module 88 retrieves information from the 
container database 80 regarding containers that have an 
alarm condition. For example, an alarm condition may occur 
when a status signal has not been or cannot be received from 
a particular container in the container network. In conjunc- 
tion with display module 94, alarm module 88 displays an 
alarm window or zone listing containers which have an 
alarm or error condition, as will be explained below. 
[0046] A container status module 92 retrieves information 
from the container database 80 regarding the status of all 
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r network which arc not full or 
which do not have an alarm condition. The container status 
module 92, in conjunction with display module 94, displays 
a window or zone which depicts the status of non-full 
containers that do not have an alarm condition, as will be 
explained in more detail below. 

[0047] An exemplary container table 81 includes a number 
of container records with each record corresponding to a 
container in the container network. Each record in the 
container table 81 includes a number of fields containing 
various information relative to the container associated with 
the record. An exemplary container record is depicted below 
in TABLE A, with field names and an explanation of the 
information stored in the respective fields. 

TABLE A 



AUTO-POLL 
INTERVAL 
AUTO-POLL FLAG 

FULL STATUS FLAG 



TABLE A-continucd 



DELAY I 
PRIMARY PREAMBLE j 



PREAMBLE 
PRIMARY PHONE 
NTJMBER 

DIAL SEODNDARY 
FLAG 

SF.mNDARY PHONE 
NTJMBER 

LAST CONTACT TIME 
PULL COST 



monitoring unit makes a i 
A secondary phone numb 

TTie date and time the las 
was established with the i 



The price charged for emptying the container. 
A numeric value reflecting the latest pressure 
reading by the monitoring unit associated with 



FULL STATUS Indicates whether the 

ACKNOWLEDGMENT acknowledged the tol 

FLAG container. 

SOFTWARE SERIAL Indicates the serial m 

NUMBER software/firmware rur 



ACCOUNT ID 

HAULER ID 

CONTAINER PHONE 
NO. 

SERVICE CO. ID 

CONTAINER MFR 

CONTAINER MODEL 
MONITORING UNIT 
STATUS ID 
USER NOTE 

EMPTY PRESSURE 
FULL PRESSURE 



W PRESSURE 



n identiHer for a billing account assoc 
ith the container. 

n identiHer for a hauler contractmg to 
contacting thi 



5d with the container. 



monitoring uni 

An identiiier for tnc service company 
associated with the container. 
An identiiier for the manu&cturer of t 

m identiiier for the model of the con 
in identiiier reflecting the status of th 
lonitoring unit associated with the cc 
I field far user-entered notes assodati 



in empty pressure 



threshold as 

A numeric value for a full pressure thresho 

associated with the container (set 

during the coimnissioning process). 

A numeric value for a V4 pressure threshok 

associated with the container (set during 

the commissioning process). 

A numeric value for a '/4 pressure thresholc 

associated with the container (set during 

the commissioning process). 



of compactions imdergone between conta 
emptying and a full container determinati 
The number of pick-ups performed by a ' 



TOTAL 

COMPACTIONS 
COMMISSION DAFE 



The most i 



performed on 
of the flrmwa 



[0048] It will be recognized that a record in the format of 
the one depicted in TABLE Awill be stored in the container 
database for each of the containers in the container network. 

[0049] It will be noted that some of the container record 
fields described in TABLE A refer to a "commissioning 
process." Although not limited to use in such container 

network systems, the invention is adaptable to container 
network systems such as those described m U.S. Pat. No. 
5.303.612 where the monitoring units 38 may be commis- 
sioned Iroiu a remote kication. The term "commissioning" 
reters generally to a process by which internal settings, such 
as values designating full pressure thresholds, of the moni- 
toring unit are modified from a remote location. Since such 
systems make a container fullness determination at the 
container site, it is useful to provide for the remote modi- 
fication of criterion used to make the fuUness determination, 
for example, the maximum compactor pressure permitted 
before a fjU determination is made. 

[0050] Referring again to TABLE A above, in applications 
where some or all of the containers in the container network 
are equipped with compactors, the container table may 
contain data representing certain pressure thresholds that are 
set during the commissioning process for that particular 
container. For example, the full pressure setting, empty 
pressure setting, 12 and Vt pressure thresholds may be 
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stored in the container table. A commissioning process may 
be performed by the central computer in which the stored 
values are communicated to the monitoring unit for the 
associated container so that y4, 14 and Va pressure flags may 
be set on the monitoring unit and conveyed to the central 
computer. Typically, the commissioning process will involve 
a data exchange, which may involve an ASCII or similar 
protocol to communicate the pressure thresholds to the 
software or firmware at the monitoring unit in a manner 
similar to the manner in which container identification and 
status information are communicated as explained below. 

[0051] The container database 80 also preferably include 
a transactions table 83, which contains records of transac- 
tions conducted relative to each of the containers in the 
container network. As wiU be explained in more detail 

below, a transaction record is created in the transactions 
table 83 by the communications module 82 each time a 
communications session is established, either by a polling 
session in the form of an outbound call initiated by the 
communications module or by the receipt of an inbound call 
initiated from a monitoring unit associated with a container 
in the container network. An exemplary transactions record 
is illustrated below in TABLE B. 

TABLE B 

DESCRIPTION 

TRANSACTION ID 



CONTAINER IDENTIFIER 



MONITORING UNIT 

SERIAL NUMBER 
DATE STAMP 
TRANSACTION TYPE 
IDENTIFIER 
PRESSURE READING 

COMPACTION COUNT 



[0052] As described above, each transaction record pref- 
erably includes a field named TRANSACTION TYPE 
IDENTIFIER which contains data, either a text string or, 
alternatively a numeric code, representing the type of trans- 
action, or the type of error occurring as a result of a 
communications session. An exemplary listing of transac- 
tion type strings suitable for implementing the invention 
appear in TABLE C below. 

TABLE C 



TABLE C-continucd 




TRANSACTION 



DESCRIPIION 



POLLDEIVIAND 
COMMISSION 

RESET 
POLLFULL 

POLLEMPTY 

ERRORFULL 

ERROREMPTY 

ERRORCALLIN 

ERRORPOLLAUTOBUSY 
ERRORPOLLDEMAND 



The transa 
polling sei 



was created as 



ERRORPOLLDEMAND 
ERRORCOMMISSION 
ERRORRESET 



or occurred during a &11 call 

^curred during an empty call 

r attempted to call but did not 
ession, typically due to 



curred durmg an on-demand 
curred durmg a comnussionmg 



[0053] Those of ordinary skill in the art will recognize that 
the transaction table provided by the present i 
provides a transaction history of all activity in the o 
network. As such, the invention provides for the presentation 
of historical data for a particular container to the user. For 
example, a graph of historical pressure readings obtained by 
periodic polls of a particular container may be presented to 
the user in graphical form by iterating through the transac- 
tion table and retrieving transaction records having the 
AUTOPOLL transaction type for a selected container. These 
transaction records may be stored in a designated table and 
a graph generated from the pressure readings and respective 
date stamps. 

[0054] In systems adhering to the teachings of U.S. Pat. 
No. 5,303,642, in which the container fullness determination 
is made al the container site, an inbound call is initiated by 
the monitoring unit 38 when the container reaches a full 
condition. As will be explained in more detail below, the 
communications module 82 manages the receipt of inbound 
calls from monitoring units 38 in the container network. The 
monitoring unit 38 is configured to set a full status flag when 
a fill! condition has been determined, based on recent 
compaction and pressure history and iteration counts. Upon 
detection of a fiiU condition and setting of the appropriate 
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5 flag, the monitoring unit 38 initiates a telephone 
entral computer 50. When a com- 
s Hnk is estabHshed, a communications session 
occurs and the monitoring unit uploads information about 
the container status and identification. In addition to receiv- 
ing the uploaded information, the central computer 50 may 
request additional information from the monitoring unit 38. 
For example, a 7-bit ASCII format may be used to commu- 
nicate commands according to the protocol as represented in 
TABLE D below. 

TABLED 

Command Description/Meaning 

<F01 The monitoring unit indicates that a "full" 

container unit designated "01" 
<C0e4 The monitoring unit indicates that the 

(hexadecimal) oi 100 (decimal) 
The central computer requests the current 



The m 



Erom the s 



tB is 80 (hexadecimal) or 



[0055] In accordance with an primary I'calure of the inven- 
tion, the compactor database is dynamically updated with 
information from the container network received by the 
communications module 82, which is adapted to receive 
inbound communications initiated at container sites and 
which, in a polling operation, is also adapted to initiate 
outbound communications to one or more containers in the 
container network. Communications module 82 cooperates 
through a communications interface with a communications 
device 84, such as a modem, to receive and transmit data. A 
poUing module 86 provides for user-modified polling 
actions in a manner that will be explained in more detail 

[0056] Referring to FIG. 5, there is illustrated an exem- 
plary display generated by display module 94 in conjunction 
with the full container module 90, container status module 
92 and alarm module 88. An exemplary graphical represen- 
tation of a full container zone preferably takes the form of 
a full container window 100 displaying a listing of full 
containers in a spreadsheet format. In accordance with well 
known operating systems, the fuU container zone 100 may 
be displayed within a main window 98. FuU containers are 
identified by a unit identifier presented in a UNIT column 
102. The unit identifier may be a text string assigned by the 
user. An account column 104 provides information regard- 
ing the business account associated with respective unit 
identifiers. A compactions column 106 contains information 
regarding the number of compactions performed on the 
container by a compacting apparatus, such as that described 
with respect to FIG. 1. The compactions information may be 
provided to the container database 80 through the commu- 
nications module 82 which may receive an inbound call or 
data signal from a monitoring unit 38 associated with the 
iicate the number of compactions performed 
r. A discrepancy column 160 provides infor- 
mation regarding the discrepancy existing between the cur- 
rent number of compactions and a running average of 
compactions required for a "full" event. The discrepancy 
column 160 provides an indicator in the i 



zone or window of an impending "full" condition so as to 
facilitate an early pick up if so desired by the user. For 
example, the discrepancy may be calculated as follows: 

DISCREPANCY-[(Average No. of Full Compac- 
tions-Current No. of Compactionsl/Average No. of 
Full Compactions]xlOO 

[0057] A pressure column 110 displays values represent- 
ing the last hydraulic pressure measured in the hydraulic 
circuit associated with the ram of a compactor for a respec- 
tive container. Pressure values are determined from the 
container database which is dynamically updated, as will be 
explained below, with data from the monitoring unit asso- 
ciated with the respective compactor. A date/time column 
112 displays the data and time that the last pressure and 
compactions data were obtained. A pick-up ordered column 
114 contains information representing to the user whether a 
pick-up has been scheduled for the particular container. A 
last pick-up column 1 1 6 displays information for the user's 
reference as to when the last pick-up occurred for the 
particular container. Those of ordinary skill will recognize 
that the fuU container zone 100 provides a visual indication 
to the user as to which containers in Ihc container network 
are in need of being emptied. 

[0058] As wiU be appreciated, some container monitoring 
units, such as those disclosed in U.S. Pat. No. 5,303,642, 
make a container fuUness determination on-site, at the 
location of the container, and provide a fullness indication 
signal via the communications link. Upon detection of a 
"full" condition, such monitoring units initiate a phone call 
to the central computer 50 and convey a full command to the 
central compuler. Thus, when applied to container networks 
in which Ihc monitoring units initiate a "ftill" call to a central 
location, the invention provides for a full container /.one 100 
that displays identifiers and other operalional information 
associated with containers, the monitoring units of which 
have initiated "full" calls. Alternatively, where the invention 
is applied to container networks in which the monitoring 
units provide pressure data to a central location and a 
fullness determination is made at the central location, the 
full container zone 100 may be used to provide a visual 
indication of full containers based on fuUness determina- 
tions made at the central computer 50. 
[0059] Still referring to FIG. 5, in accordance with 
another feature of the invention, a container status zone or 
window 150 is also displayed to the user within the main 
window 98. An exemplary graphical representation of con- 
tainer status zone 150 preferably takes the form of a con- 
tainer status window displaying a listing of containers in the 
container network in a spreadsheet format. In a manner 
similar to the fuU container zone 100 described above, the 
container status zone 150 provides a unit identifier column 
152, an account information column 154, a pressure reading 
column 156, a % CALL IN column 157, a compactions 
column 158, a discrepancy column 160, a last contact 
column 166, and a last pick-up column 162. The % CALL 
IN column 157 provides an indication of the percentage 
represented by the current pressure compared to a threshold 
"call-in" pressure. The "call in" pressure represents a pres- 
sure value at which a fuUness determination is made by the 
it 38. The last column 166, indicates to the 
r when the last contact was made relative to the Usted 
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170 is provided for depicting to the user a list of containers 
in the container network which are currently experiencing an 
alarm condition. Such alarm conditions may include a 
failure of a particular monitoring unit in the container 
network to report (or make an inbound call) to the central 
computer or a failure of a pressure transducer in the moni- 
toring imit associated with a particular container. This alarm 
information is provided to the container database by the 
monitoring tmits associated with containers in the network. 
Preferably, this information is obtained during an outbound 
polling session initiated by the central computer as will be 
explained below. Alternatively, the monitoring units may be 
equipped with appropriate control routines to send a signal 
to the central computer to indicate a particular failure of a 
component, such as a pressure transducer. A unit identifier 
column 172, account column 174, date/time column 176 and 
last contact column 178 iire preferably displayed in the 
alarm zone 170. In addition, a transaction column 180 
provides an indicator, such as a text string, for revealing to 
the user the type of error or alarm experienced with respect 
to a particular container. 

[0061] The information presented m the full container 
zone 100, container status zone 150, and alarm zone 170 is 
retrieved from the container database 80 by the full con- 
tainer module 90, container status module 92, and alarm 
module 88, which are adapted to recognize the creation of 
new transactions in the container database 80 by the com- 
munications module 82 or otherwise as will be described. 
Moreover, as will be described in more detail below, the full 
container zone 100, container status zone 150 and alarm 
zone 170 arc continuously updated based on information 
received by communications module 82 and written to 
database 80. When new data is received, the full container 
module 90 redraws the full container zone 100 to update the 
display. Similarly, the container status module 92 redraws 
the container status zone 150 and the alarm module 88 
redraws the alarm zone 170. 

[0062] FIC. 6 is a flow diagram illustrating the steps of 
operation of an exemplary process performed by the full 
container module, stahis module and alarm module to main- 
tain an updated listing of full containers, container status and 
containers having an alarm condition, respectively. 

[0063] The exemplary process is preferably performed 
upon the completion of an inbound call received from a 
reporting monitoring unit 38 or upon completion of an 
outbovmd call initiated by the communications module 82 as 
a result of an on-demand poU initiated by the user or as a 
result of a polling session scheduled by the user. The main 
thread of execution includes steps to check for the comple- 
tion of an inbound or outbound call, represented generally at 
step 185. This check may be implemented, for example, as 
a program message routed or threaded through the operating 
system associated with the communications device or 
modem 84. If it is determined that neither an inbound nor an 
outbound call has been completed, the process branches lo 
step 186 and returns to the main thread. 

[0064] If at step 185 it is determined that an inbound or 
outbound call has been completed, the process initiaUzes the 
container table, for example, setting a pointer to the first 
record in the container table, at step 187. At step 188, the 
next container record (in the case of the first iteration, the 
first container record in the container table) is retrieved by 



the full container module 90. At step 189, a determination is 
made as to whether or not the full status flag, in the field 
FULL ST.AFUS FLAG in the container record is set to a 
"true" value, indicating the monitoring unit 38 associated 
with the container has reported that the container is full. If 
so, the process branches to step 190 where the container 
record is added to a full container listing temporarily stored 
in memory. The process then returns to step 188 where the 
next container record is retrieved from the container table. 

[0065] If al sicp 189. ii is dclumincti ihal ihc full status 

to step 191 where the transaction tabic is examined by the 
alarm module 88 to determine the most recent transaction 
associated with the container (i.e., having the identifier for 
the container in the UNIT IDENTIFIER field). At step 192, 
a determination is made as to whether the most recent 
transaction is an alarm type transaction, for example, an 
ERRORFULL or ERRORBADTRANSDUCER transaction 
type contained in the TRANSACTION TYPE IDENTIFIER 
field of the transaction record. If so, the container record is 
added to an alarm listing temporarily stored in memory at 
step 193. The process then returns to step 188 where the next 
container record is retrieved. 

[0066] If at step 192, it is determined that the most recent 
transaction is not an alarm type transaction, then the process 
continues to step 194 where the container record is added to 
a status listing temporarily stored in memory. At step 195, 
the process delcnyiincs whether or not llic cud of Ihc 
container table has been reached. If nol, Ihc process 
branches back to step 188 lo retrieve the next container 
record. If so, the process continues to step 196 where the full 
container module 90, in conjunction with the display module 
94, redraws the full container zone to display the listing of 
full containers stored in the full container listing. Similarly, 
at step 197, the alarm module 88 in conjunction with the 
display module 94, redraws the alarm zone to display the 
listing of containers stored in the alarm listing. Likewise, at 
step 198, the container status module 92, in conjunction with 
the display module 94, redraws the container status zone to 
display the listing of containers in the status listing. The 
process then returns to the main thread of execution at step 
186. 

[0067] As will be recognized from the exemplary process 
described above, a given container in the container network 
appears in only one place on the display 98. That is, a given 
container is identified either in the full container zone, the 
alarm zone or the container status zone. Accordingly, a user 
may quickly determine which of the containers in the 
container network are full by viewing the fidl container 
zone, which also provides key information as described 
relative to FIG. 5. Similarly, the existence of any alarm 
conditions on containers in the network may be quickly 
determined by viewing the alarm zone. The status of the 
remaining containers in the container network — those that 
have neither a full condition or an alarm condition — may be 
quickly determined from the container status zone. With 
each instance of an inbound or outbound call, the full 
container module 90, container status module 92 and alarm 
module 88 operate to update the display to reflect changes in 
the status of the containers in the network. Thus, the user is 
presented with an up-to-date display which permits quick 
determination of the status of all active containers in the 
container network. 
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[0068] Referring now to FIG. 7, according to another 
aspect ot the invention, a user intertace is provided for 
permitting a user to set and moditv the automatic polhng 
parameters tor particular containers in the container net- 
work. In response to user aclivaiion ol Ihc user inlcrlace 
selection device 62 (FIG. 3), or in response to appropriate 
alpha-numeric entry through keyboard 64 (FIG. 3), a COM- 
PACTORS feature 200 displayed in the main window 98 
may be activated to provide a puU-down display 202, which 
includes an ADD/EDIT/COMMISSION option 201 to 
enable a user to edit parameters associated with a selected 
container and to configure automatic polling features for a 
selected container. 

[0069] When the ADD/EDIT/COMMISSION option 201 
is selected by the user, i.e., when the user interface selection 
device is used to move a pointer over the ADD/EDIT/ 
COMMISSION option 201, the user is presented with the 
dialogue box or window 250 shown in FIG. 8 for displaying 
parameters associated with a selected container based on a 
corresponding record in the container table 81 (FIG. 4). 
When the COMPACTORS tab 252 is selected by the user, a 
COMPACTORS dialogue pane 251 is displayed and pre- 
sents information in the container table 81 in a record 
associated with a particular container, identified in a UNIT 
NAME box 254. Other tabs and associated panes may be 
provided to enable the user to view the container database 
information in different formats, for example, by account, 
hauler, site or region. The COMPACTORS dialogue pane 
251 also permits a user to view and modify records in the 
container table 8T (FIG. 4). The user selects the container 
information to be viewed by inputting an identifier in the 
WASTE EDGE ID box 253 in a COMPACTOR section 255 
of the COMPACTORS dialogue pane 251. A scrolling 
control 257 permits the user to scroll through a Hst of 
container identifiers, or a user may search for a particular 
container identifier by typing the first few characters of the 
UNIT NAME associated with the container into a search box 
258. When the user inputs or selects a given container 
identifier in the WASTE EDGE ID box 253, various infor- 
mation in the container record associated with that selected 
container identifier is retrieved from the container table and 
displayed in corresponding boxes in the COMPACTORS 
dialogue pane 251. 

[0070] In accordance with a primary aspect of the inven- 
tion, the user may activate or deactivate automatic polling 
and set the automatic poUing interval for a selected container 
using the AUTOPOLL section 260 of the COMPACTORS 
dialogue pane 251. For example, as illustrated in FIG. 8, a 
container identifier "30" appears in the WASTER EDGE ID 
box and the AUTOPOLL section 260 indicates with a check 
box 262 that automatic polhng is activated for the identified 
container, that is the AUTO-POLL FLAG (TABLE A) field 
in the container record is set to a "true" value. An automatic 
polling interval box 264 indicates the automatic polling 
interval set in the AUTO-POLL INTERVAL field in the 
container record. The COMPACTORS dialogue pane 251 
permits the user to toggle the AUTO-POLL FLAG by 
interacting with, i.e., pointing and clicking, on the check box 
262. The user may change the AUTO-POLL INTERVAL 
value by typing an appropriate number in an autopoll 
interval box 264. The modified fields in the container record 
may be stored in the container table 81 when the user selects 
a SAVE control button 265. Thus, the COMPACTORS 
dialogue pane 251, which may be generated by the poUing 



module 86, or a separate module, in conjunction with the 
display module 94, permits user-modification of the polhng 
parameters associated with each container in the container 
network. 

[0071] As will be recognized liom FIG. 8, the COMPAC- 
TORS dialogue pane 251 provides for display and modifi- 
cation of other fields in the selected container record. For 
example, the full pressure, required full compactions, empty 
pressure and required empty compactions parameters may 
be modified by user-entry of new values into corresponding 
boxes. Similarly, the primary and secondary phone numbers 
that arc dialed by the monitoring unit associated with the 
given container may be modified. The updated values may 
be uploaded to the monitoring unit of the given container by 
user-selection of the COMMISSION NOW control button 
270, which causes a communications link to be established 
with the monitoring unit associated with the given container 
and the appropriate parameters uploaded. 

[0072] Once the automatic polling parameters have been 
input by the user for a particular container, automatic polling 
is facilitated in the background by the communications 
module 82 by iterating through the container table 81 and 
creating poll sessions according to the status of the value of 
the respective AUTO POLL FLAG in each container record. 
These poll sessions are queued into a stack for execution by 
the commvmications module 82 in a manner that will be 
explained below. FIG. 9 depicts a flow chart showing the 
steps performed by an exemplary communications module 
and polling module to create poll sessions according to the 
invention. The communications module 82 iterates through 
the container table 81 in a periodic manner, that is, continu- 
ously as part of the communicniions Ihrcad ninnnig in Ihe 
background to the main thread in a niulli-lasking operating 
environment. At step 360, ihe next ct)iilainer recurd is 
retrieved from the container table 81. At step 362, the 
communications module 82 determines whether the AUTO 
POLL FLAG is set to a true value for the container. If not, 
the process branches back to step 360 where the next 
container record is retrieved. If so, the process then deter- 
mines whether the AUTO POLL INTERVAL for the con- 
tainer has expired at step 364. This determination is prefer- 
ably made by subtracting the time indicated in the LAST 
CONTACT TIME field of the container record from the 
current time and determining if the result exceeds the value 
specified in the AUTO POLL INTERVAL. If the interval has 
not yet expired, the process branches back to step 360 where 
the next container record is retrieved. If, at step 364, it is 
determined that the interval has expired, a poll session is 
created for the container at step 366 and at step 368 the poll 
session is added to or queued into the calKng session stack, 
the operation of which will now be explained. 

[0073] The communications module 82 preferably man- 
ages communications with monitoring units in the container 
network using a first-in first-out stack in which calling 
sessions are queued. I'he term "calling session" as used 
herein refers to an outbound polling session that is scheduled 
according to the automatic poUiiig features of the invention, 
or to an on-demand outbound polling call requested by the 
user, or to a full or empty inbound call initiated from a 
monitoring unit 38. When a poll session is created as 
describe above in reference to FIG. 9, the session is queued 
into a calling session stack. The communications module 82 
then initiates poUing calls according to the poU sessions 
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queued into the stack on a first-in-first-out basis. In this 
manner, in accordance with the advantages and objectives of 
the invention, a number of polling sessions may be queued 
into the stack and performed while the central computer 50 

is unattended. 

[0074] According to another feature of the invention, the 
communications module 82 is adapted to initiate polling 
calls while permitting the receipt of inbound calls from 
monitoring units in the container network. Thus, polling 
sessions may be scheduled and performed without jeopar- 
dizing the receipt of high priority calls, such as inbotmd calls 
to indicate full containers. FIG. 10 is a flow chart depicting 
a process for creating calling sessions in accordance with the 
invention. At step 310, the next calling session in the session 
stack is conducted by the communications module 82. At 
step 312, an inter-session delay is executed in order to permit 
receipt of inbound calls. At step 314, a determination is 
made as to whether or noL an inbound call is received. If not, 
the next calling session queued into the session stack is 
conducted as the process returns to step 310. If, at step 314, 
an inbound call is received, the communications module 82 
next determines, according to the communications protocol 
described above at step 316, whether or not the inbound call 
is an empty call. If so, an empty call session is created at step 
318 and placed in the calling session stack at step 320. 
According to a primary aspect of the invention, and as 
illustrated in FIG. 11, the empty call session is placed at the 
head node 352 of the session stack 350 so that the empty call 
session is performed prior to any other calling sessions 
queued into the stack. In other words, the other calling 
sessions queued into the stack arc preempted by the empty 
call session. This permits immediate execution of the empty 
call session so that the empty call inbotmd from the corre- 
sponding monitoring unit may be received and the transac- 
tions table and container table updated accordingly. After 
step 320 is performed, the process branches back to step 310 
to conduct the next calling session queued into the session 

[0075] If at step 316, it is determined that the inbound call 
is not an empty call, the process continues to step 322, where 
a determination is made as to whether the inbound call is a 
full call. If not, the process returns to step 310 to conduct the 
next calhng session in the stack. If so, the process creates a 
full call session at step 324 and places the full call session 
at the head node of the calling session stack at step 326. In 
this manner, the full call session is executed m a preemptive 
manner relative to the other calling sessions queued into the 
calling session stack to permit immediate receipt of the 
inbound full call and appropriate updating of the container 
table and transactions table. 

[0076] As described briefly above, an exemplary commu- 
nications session according to the invention involves a 
sequence of data interchanges or queries between the central 
computer and one or more of the monitoring units in the 
container network. Each session preferably involves a 
sequence of printable text type commands or responses. 
Each command has an associated retry covmt and timeout 
interval. If the retries are exhausted or the timeout interval 
is exceeded, the session is aborted and a transaction denoting 
this error condition is created in the transactions table 83. 

[0077] FIG. 12 illustrates an exemplarj' dialog for a 
polling session. Once a communications link is established. 



commands are transmitted by the central computer 50 using, 
for example, an ASCII sequence of characters. For example, 
the central computer 50 may first request the unit number of 
the container using the command "<U" and the monitoring 
unit 38 may respond with an ASCII sequence in the form 
">U01 " to respond with a unit number "01". According to 
this exemplary portocol, each of the commands illustrated in 
the left table in FIG. 11, except for the hang-up command, 
seeks a response in the format as shown in the right table. 
Moreover, a retry cotmt and timeout interval are assigned to 
each command in order to provide for the detection of error 
conditions, due for example to interference or noise in the 
communications link. If the timeout interval is exceeded, the 
command transmission is retried. If the retry count is 
excectlcti, an error transaction is stored in the transaction 
table for the container. 

[0078] It win be readily apparent from the foregoing 
detailed description of the invention and from the illustra- 
tions thereof that numerous variations and modifications 
may be effected without departing from the true spirit and 
scope of the novel concepts or principles of this invention, 
the scope of which is defined in the appended claims. 
Although the preferred embodiment has been described with 
reference to monitoring units, such as those described in 
U.S. Pal. No. 5,303,642, that make a container fiillness 
determmation al the container site, those of ordinary skill in 
the art will recognize from the foregoing that the primary 
features of the invention are adaptable to container network 
systems, such as those disclosed in U.S. Pat. No. 5,016,197, 
in which fullness determinations are made at the central 
computer 50. In such an adaptation, the full container 
module 90 may make a full determination based on a 
comparison of pressure data communicated by the monitor- 
ing units to a maximum value, and the full container display 
zone updated based on the fullness determination made by 
the central computer. 

[0079] It will also be recognized that, while the invention 
has been described with reference to containers that have 
compactor assemblies associated with them, the invention is 
also adaptable to open-top type containers which have no 
compactor assemblies associated with them. The fullness of 
such containers may be determined by a human attendant, 
who would initiate a telephone call to report a full condition. 
According to the invention, a full call switch may be 
provided at the container site, preferably as part of the status 
monitor, to initiate a full call when activated by a human 
operator. The telephone number to be called may be pro- 
grammed from the central computer and previously 
uploaded to the status monitor during a commissioning 
session. Alternatively, the human attendant may be provided 
with a designated number to call when the container needs 
to be emptied. A voice-activated or telephone key diahng 
interface could also be provided to enable the human atten- 
dant to input information identifying the container to be 
emptied. The commiinical ions module of the present inven- 
tion would be adapted to create a FULL transaction in the 
transaction table for the identified container, and the full 
container module adapted to update the full container dis- 
play zone to list the full container. 

[0080] It win also be apparent to those of ordinary skill in 
the art that invention is applicable to networks which are 
distributed over a wide area. For example, the invention is 
applicable to Internet-based systems which monitor the 
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status of a number of containers in a container network. 
Such a system could make use of communications between 
the central computer and the monitoring units coupled to one 
or more of the waste c 



[0081] In addition to being able to monitor and/or manage 
the status of the waste containers from a display device 
coupled to the central computer or associated with the 
central location, in at least one embodiment ot the present 



number of people. This would continue to allow the data to 
be centrally managed and maintained, but would also allow 
multiple individuals to more readily have direct access to the 
information. This would be particularly useful in organiza- 
tions where multiple individual may have an interest in the 
data being seneiated and/or business ethciencies can be 
enhanced by making the information more widely available. 

[0082] For example, the information could be used by 
individuals in accounts payable to verify bills received from 
the refuse hauler, not only to verity that a pick up occurred 
on the date indicated, but that the pick up occurred as a result 
of a pick up request by the system. Additionally, the mlor- 
mation could be used by individuals responsible for main- 
tenance and repair of the compactor units. A dispatcher in 
repair may be able to remotely diagnose possible problems 
with a particular waste container by viewing the past use 
data, thereby insuring that the repair technician has the 
appropriate replacement parts prior to being dispatched for 

[0083] In at least one instance the remote monitoring is 
accessible via one or more computers coupled to a public 
global wide area communication network, like the Internet. 
In these instances it would be further beneficial if the status 
information can be accessed and viewed using standard 
Internet browser software, thereby allowing users to access 
the information without first having to install any cu.stom or 
use specific data access software. 

[0084] Potentially any data available locally at the central 
computer data server from the data base could be similarly 
made available at one or more of the remote monitors. 
Management control could also be performed at one or more 
of the remote monitors. Alternatively the data or control 
functionality could be made selectively available. Different 
user log-in accounts could be used to provide selective 
access to different levels of control or types of information. 
In this way, any sensitive data could be protected or access 
could be simphfied so as to be only focused upon the data 
or elements that the particular user is interested in. 

[0085] FIG. 13 illustrates the remote access portion of one 
exemplary system 400 for remotely managing a waste 
container network including a central computer/data server 
402 and one or more remote monitors 404. The central 
computer/data server 402 and the remote monitors 404, are 
each communicatively coupled to a communication network 
406. As noted previously, in at least one instance the 
Q network 406 is a public global wide area 
twork, like the Internet. This would 
enable any browser enabled computer that is coupled to the 
Internet to potentially provide remote monitoring function- 
ality. Correspondingly, the specific nature of the communi- 
cation connection can take one or more of several different 



wcU known forms. For example, access to the network could 
be via a dial-up modem and telephone line connection. 
Alternatively, the network could be accessed via a hard 
wired or wireless connection, through the use of, for 
example, a network adapter or radio transceiver. The central 
computer/data server 402 would continue to have commu- 
nication links 36 with the one or more monitoring units 38 
coupled to the one or more container 12, as illustrated in 
hid. 2. Although it is possible that the monitoring units 38 
could also be communicatively coupled to the central com- 
letwork 406. 



[0086] HG. 14 illustrates a simplified block diagram of 
one embodunent of the central computer/data server 402 
illustrated m FIG. 13. The central computer/data server 402, 
generally, is consistent with the block diagram of the com- 
pnlcr illusl rated in FIG. 3, and the block diagram illustrating 
the relationship between the various modules and database 
in VUi. 4. The processor 408 generally corresponds to the 
microprocessor 52, illustrated in FIG. 3, and the memory/ 
storaee element 410 is generally consistent with memory 54 
and storage device 58, also shown in FIG. 3. Similarly, the 
container communication unit 412 is consistent with the 
communications device 84, illustrated in FIG. 4, and pro- 
vides communications with the one or more waste container 
12 and corresponding monitoring units 38. 

[0087] In the illustrated embodiment a container database 
414, corresponding to the container database 80, is stored 
within memory/storage 410. Additionally stored in the 
memory storage 410 are program data and instruction 
sequences 416, which could be used to implement the 
various iiKidulcs ui cuinponents, also illustrated in FIG. 4. 

[00881 flic central computer/data server 402 illustrated in 
FIG. 14, additionally includes a monitor access interface 
unit 418, which facilitates comnniiiicalii)ns between the 
central computer/data server 402 and the one or more remote 

previously the specific nature of the communication con- 
nection can take one or more of several different well known 
forms. Correspondingly, the monitor access unit could be 
one or more of several types of network connecting devices 
ranging from the previously noted dial-up modem to a radio 
transceiver. 

[0089] The central computer/data server 402 also addi- 
tionally includes an interface translation module 420, which 
can be implemented as a sequence of programming instruc- 
tions and/or corresponding data, stored in a computer read- 
able medium, such as a memory or storage device 410. The 
interface translation module 420 converts the data produced 
or to be received by the various database queries into a form 
which is compatible with the remote monitors 404. In at 
least one instance, the interface translation module 420 
converts the container database 414 output into hypertext 
markup language instructions or other standard Internet 
programming language, which can be viewed using a web 
browser software program being executed on the remote 
monitor 404. Data can be received back from the remote 
monitor through the web browser interface, and correspond- 
ingly converted into a form by the interface translation 
module 420, which can be used with the container database 
414. In this way, any one who has access to the Internet 
could theoretically have access to and remotely manage the 
r network. 
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[0090] FIG. 15 illustrates a simplified block diagram of 
one embodiment of a remote monitor 404, illustrated in 
FIG. 13. The remote monitor 404 includes a processor 422, 
which is coupled to a memory/storage unit 424, and a data 
server interface unit 426. Similar to the monitor access 
interface unit 418 of the central computer/data server 402, 
the data server interface unit 426 can take one or more of 
several different well known forms for coupling to a com- 
munication network 406, the specific form being at least in 
part dependent upon the type of the communication net- 

[0091] However, it is possible for the monitor access 
interface unit 418 to be different than the data server 
interface unit 426. This is especially the case where the 
communication network 406 is a public global wide area 
commtmication network, Ukc the Internet, where multiple 
different types and ways of connecting to and communicat- 
ing over the Internet have been developed. Where the 
communication network 406 is the Internet, the central 
compiitcr/'dala server 402 could be coupled to the commu- 
nication network in any one or more of the ways that have 
been developed for connecting to the Internet, and while one 
or more of the remote monitors 404 might be connected in 
a similar manner to the Internet, they could also alternatively 
be connected in a manner consistent with any of the other 
various alternative ways to connect to the Internet. Similarly, 
the different remote monitors 404 might also be coupled to 
the communication network 406 using various different 
types of alternative technologies, without impairing the 
ability of the remote monitor units 404 to communicate with 
the central computer/data server 402. 

[0092] While the remote monitors 404 and central com- 
puter/data server 402 have been shown as being coupled 
together via a communication network 406, it is also alter- 
natively possible that the two could be coupled together 
directly, independent of a corresponding communication 
network 406. 

[0093] The memory/storage unit 424 of the remote moni- 
tor 404, includes sequences of programming instructions 
and/or corresponding program data 428. In at least one 
embodiment, the memory/storage unit 424 includes pro- 
gramming instruction/data sequences for implementing web 
browsing software 430. 

[0094] The remote monitor 404 further includes a user 
output device 432 upon which information received from the 
central computer/data server 402 can be presented to the 
user, one such example including a display device 434 or 
video monitor, upon which the received information can be 
displayed. The remote monitor still further includes a user 
input device 436 for receiving user input and conveying the 
received user input to the central computer/data server 402. 
Examples of user input devices 436 include a keyboard 438, 
a mouse or other pointing device 440. 

[0095] From the foregoing, it will be observed that numer- 
ous variations and modifications may be effected without 
departing from the spirit and scope of the invention. It is to 
be understood that no limitation with respect to the specific 
apparatus illiLstrated herein is intended or should be inferred. 
It is, of course, intended to cover by the appended claims all 
such modifications as fall within the scope of the claims. 



What is claimed is: 

1. A system for remotely managing a waste container 
network, the container network including one or more waste 
containers, each container having associated therewith a 
monitoring unit for communicating status information to a 
remote location, the system comprising: 

a computer data server comprising a container commu- 
nication unit for communicating with the monitoring 
unit of each of the one or more waste containers and for 
receiving status int'onnation, a processor for executing 
a plurality of prcsioixtl instructions including instruc- 
tions for creating and maintaining a container database, 
based at least in part upon the status information 
received, and a monitor access interface unit for pro- 
viding an interface between the computer data server 
and one or more remote monitors; and 

one or more remote monitors each including a data server 
interface unit communicatively coupled to the monitor 
access interface unit of the computer data server, a user 
output device for supplying waste container status 
information received from the computer data server via 
the server interface unit to a user, and a user input 
device for supplying information received from a user 
to the computer data server via the data server interface 

2. The system of claim 1, wherein the monitor access 
interface unit of the computer data server and the one or 
more data server interface units of the one or more remote 
monitors are communicatively coupled together via a com- 
munication network. 

3. The system of claim 2, wherein the communication 
network is a public global wide area communication net- 

4. The system of claim 2, wherein the computer data 
server further comprises an interface translation modtile 
which converts the waste container status information into a 
report or form which can be readily received by the output 
device via the communication network. 

5. The system of claim 4, wherein the output device of at 
least some of the one or more remote monitors includes a 
display device upon which the waste container status infor- 
mation is adapted for being displayed. 

6. The system of claim 4, wherein the report or form 
includes selectable links or fields which are adapted for 
receiving user selection or data input via the user input 
device for receipt by the interface translation module of the 
computer data server via the communication network. 

7. The system of claim 6, wherein the user input device 
includes at least one of a keyboard, a mouse, and a pointing 
device. 

8. The system of claim 4, wherein the one or more remote 
monitors includes a processor and browser software instruc- 
tions being executed on said processor. 

9. The system of claim 8, wherein the interface translation 
module converts the waste container status information into 
hypertext markup language instnictions for display on the 
user output device by the processor executing browser 
software instructions. 

10. A method of remotely monitoring a waste container 
network, the container network including a plurality of 
waste containers, each container having associated therewith 
a monitoring unit for monitoring status information associ- 
ated with the container and for communicating the status 
information to a remote location, the method comprising; 
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receiving waste container status information at a central 
computer; 

storing the status information in the a database and on the 
central computer; and 

accessing the waste container status information via one 
or more remote monitors communicatively coupled to 
the central computer via a communication network. 

11. ITie method of claim 10, wherein accessing the waste 
container status information includes converting the status 
information into a report or form which can be readily 
received by an output device of the one or more remote 

12. The method of claim 11, wherein accessing the waste 
container status information includes populating one or 



more fields included within the report or form with user data 
supplied via a user input device. 

13. The method of claim 11, wherein converting the status 
information includes converting the information into hyper- 
text markup language instructions for being accessed via 
browser software being executed by a processor on the one 
or more remote monitors. 

14. The method of claim 10, wherein the communication 
network is a pubUc global wide area communication net- 

15. The method of claim 10 wherein accessing the waste 
container status information includes supplying information 
at one or more of the remote monitors on a display device. 
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